An OSH software contract: support, SLAs, data rights and changing providers
An OSH software demonstration shows how the team could work. The contract defines what will be delivered, what happens during an incident and how information can be recovered if the relationship changes. Reviewing both together prevents a commercial expectation from turning into a disagreement about scope.
Start with the processes you need: assessments, actions, training, inspections or document coordination. The entry on OSH software helps organise that map. Then translate it into verifiable terms, with owners and evidence of acceptance.
Describe the purchase independently of a presentation
The scope schedule should identify modules, legal entities, sites, user profiles, storage and included professional services. Clarify whether migration, initial training, integrations and configuration changes are included in the price or quoted separately. The answer should be traceable to a version accepted by both parties.
Include the company’s own contributions: data quality, availability of contacts, permission validation and process decisions. Implementation can stall even when the supplier delivers if nobody on the customer side has authority to approve the result.
Translate the SLA into understandable situations
A service level agreement should make sense to the people using the system. Distinguish service availability, support hours, initial response time and resolution or recovery targets. “Fast assistance” does not allow anyone to check whether an incident received the agreed treatment.
| Situation | Question for the contract |
|---|---|
| The service cannot be accessed | How is an interruption logged, measured and escalated? |
| A specific process stops working | Who determines severity and what workaround is offered? |
| Maintenance is scheduled | What notice and maintenance windows apply? |
| A user needs assistance | Which channels, languages and support hours are covered? |
These are negotiation criteria, not commercial terms attributed to Sabentis. Also check what evidence the customer receives after an incident and who coordinates communication when an integration with another system is involved.
Clarify data and permitted uses
Define the information supplied by the customer, the records generated by the service and each party’s permitted uses. The phrase “data ownership” does not replace clear purposes, access, retention and return arrangements. The Spanish Data Protection Agency explains controller and processor relationships (in Spanish), which require assessment where the GDPR applies.
For a Colombian operation, review the applicable framework and international data flows with the appropriate owner. Avoid copying a clause from another jurisdiction without checking its suitability. The entry on OSH health data helps identify information requiring particularly clear boundaries.
Test an exit before you need one
Request a sample export containing records, attachments and relationships. A file of names and dates may be insufficient if the link between assessment, action and evidence disappears. Ask for a field dictionary and verify that another person can interpret the data without relying on the original interface.
- Delivery formats and documentation of their structure.
- Cost, timing and owners for a final export.
- A read-access period during transition.
- Backup, retention and deletion arrangements at termination.
- Assistance available for migration problems.
In an illustrative example, a company changes providers when its agreement expires. Testing the export earlier reveals missing attachments and ambiguous fields while the service remains active. The OSH software migration guide develops this check.
A joint review by procurement, OSH and IT
Allocate review tasks by expertise, then maintain one outstanding-items list. OSH validates processes and operational continuity; IT checks security and integrations; procurement reviews scope and financial terms; legal and privacy teams assess the relevant obligations. Each item should end in a decision rather than an unowned comment.
Record assumptions explicitly during this review. If a requirement depends on a separate integration or service package, identify that dependency in the acceptance plan. Revisit the agreed scope after a material change to the implementation, so that the documents remain consistent with the operation being delivered.
Prepare negotiations with an OSH software RFP and check controls against the IT security review guide. When speaking with Sabentis, bring specific scenarios and ask for the proposal and contract to reflect the agreed scope.
Checklist for reconciling the contract and demonstration
Before accepting the proposal, walk through a complete purchasing scenario with Procurement, OSH and IT. This review helps locate conditions often scattered across emails, commercial appendices and technical documents.
- Link every decisive demonstration requirement to an expressly agreed clause, appendix or acceptance criterion that can be located later.
- Simulate an out-of-hours incident and confirm the available channel, applicable calendar and starting point for each response commitment.
- Request an example invoice involving additional users, entities or storage to understand exactly how incremental charges are calculated.
- Confirm who receives and decides on service changes that could affect preventive processes or integrations with other systems.
- Open a sample export in an independent tool and check the link between a record, its document and closure evidence.
Frequently asked questions
Are an SLA and support hours the same thing?
No. An SLA sets service commitments, while support hours define when a particular type of assistance is available. Check how an incident beginning at night or on a public holiday is measured. Distinguish initial response, recovery and resolution, with measurable definitions and identifiable exceptions.
How does exporting data differ from being able to change provider?
An export is only part of a transition. You also need to interpret fields, retrieve attachments, preserve relationships and establish a cut-off date. Request a trial involving a complete case and agree who resolves delivery problems before access to the previous system ends.
Is a clause saying the data belongs to the customer enough?
It does not explain everything each party may do with the information. Purposes, access, subcontracting, retention and return require definition. Where one entity processes data for another, review the controller’s and processor’s corresponding obligations under the regime applicable to that particular operation.
How can I avoid paying twice for a requirement included in the offer?
Identify the accepted scope version and its dependencies, including configuration or integration services. When a change is proposed, ask which new need justifies it and what its impact will be. An agreement register helps distinguish a legitimate extension from a requirement already contracted.
Legislation and consulted sources
- AEPD: controllers and processors. Spain and GDPR: guidance on the relationship where a provider processes data for its customer. Spanish text.
- Law 1581 of 2012. Colombia: data protection framework relevant to defining responsibilities and permitted information use. Spanish text.
Sources consulted on 6 October 2026.
